Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Disk Arrays

The layout for the DSS system on a disk array is much simpler than it is on traditional disk drives. The minimal configuration for a DSS system on a disk array should look something like this:


Element (# of Disks) Comments

System (1+) The system disk is used for the operating system, swap file (if applicable), user files, and Oracle binaries. If possible, mirror this disk for additional fault tolerance.
Redo log (0) Little or no update activity. Because very little update activity is involved with decision support activities, the log files are not active and are not a bottleneck to the system. These drives can be better used for data files. The redo log files can reside on the same disk as the system.
Redo log (1+) Some update activity. You should have at least one log volume. This volume should be made up of at least two physical disks using RAID-1. If you use only one log volume, performance is degraded during archiving because the sequential nature of the log writes is disrupted.
Archive logs (0) Little or no update activity. As with the redo log files, archiving is minimal and not necessary. The archive log files can also reside on the system disk.
Archive logs (1+) Some update activity. The number of disks needed for the archive log files is determined by the amount of data you have to archive. This data can be written to tape as necessary.
Data and index (1+) Because you always get concurrent access to disks with a disk array, you do not have to split the data and indexes into separate volumes. The number of disks you need for data and index is determined by the amount of random I/O your user community generates.

Both the data files and the indexes should be striped over as many disk drives as necessary to achieve optimal I/O rates on those disks. From Chapter 14, “Advanced Disk I/O Concepts,” remember that you can only push a disk drive to a maximum random I/O rate.

Unlike traditional disk drives, when you use a disk array, the data is automatically striped across all the disk drives; therefore, it is necessary to create only one tablespace and table for all your data. You do not even have to put indexes into another tablespace—although I recommend doing so for other reasons (such as monitoring and maintenance).

With traditional disk partitioning, it is difficult to manage hundreds of data files and disks; with a disk array, you can manage hundreds of disks with just a few data files. Of course, Oracle has a 2-gigabyte limitation on the size of a data file, but this is easily resolved by creating a data file for every 2 gigabytes of space you need. The data files can all reside on the same disk array volume. By splitting tablespaces into several data files with tables striped across them, all residing on the same logical volume, you can take better advantage of the Parallel Query option.

If you use a disk array, many of the management tasks and load balancing tasks are greatly simplified. With the disk array, you also have the option of using fault tolerance without affecting system performance. Of course, using fault tolerance requires significantly more disks.

I recommend that you use a disk array if possible. Software striping is fine, but if your system is under heavy loads (as it is with a typical DSS system), you can achieve better performance by offloading the striping overhead to a hardware RAID controller.

Hardware Considerations

When choosing hardware to use with a DSS system, consider these factors:

  Low user load. Not many concurrent processes/threads simultaneously access the system unless you are taking advantage of the Parallel Query option.
  High I/O load. I/Os are concurrent and heavy, with mostly random I/O.
  Low network traffic. The typical DSS does not use the network in any significant fashion (unless it is used for data loading).

If you can take advantage of the Oracle Parallel Query option, many different processes will use the machine at once; an SMP or MPP machine should scale very well. Because an SMP architecture uses CPUs based on the processes that are available to be run, if you always have a runnable process available for each CPU, you should see good scaling by adding additional processors. With an MPP machine, you see a similar effect but on a much larger scale.

Because there is much random access to the disks, you can benefit from a disk array. I prefer hardware striping to OS striping because hardware striping does not incur any additional overhead for the operating system and does not take up valuable CPU cycles. If hardware striping is not available, OS striping is a good alternative.

Because network traffic is probably not very high, you really don’t have to worry too much about segmenting the network. If you are constantly updating the DSS system from the OLTP system, however, network traffic may be more of an issue.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.